前一天我們有提到SOLID，我們今天就來談談為啥我們需要了解SOLID? 他能幫助我們甚麼?
SOLID是一種設計原則，主要是透過觀念讓團隊降機Code Review成本，達到clean code提高程式可讀性讓你的程式就像開發文件，與提高程式複用性讓你一處寫而不需百處收，您的程式是不知不覺的就有種”高內聚、低耦合”的味道，是不是很驚奇!?那還在等甚麼，趕快來聊解看看吧!!

PS:高內聚、低耦合以component來說，就是元件內的資料相關性高，元件與元件之間的相互依賴性低。

物件導向設計原則-SOLID
S: 單一職責原則 Single Responsibility Principle (SRP)

這在任一前端框架的官網都被強調，單一職責顧名思義，就是一個人只會做一件事，那若換說在程式裡面呢?

1. 你是否曾經有捉襟見肘的窘境，當改好A bug，B bug就出現。
2. 你是否有曾經被要求寫單元測試，然後看了自己的程式耦合性過高不好測試，乾脆不測了。
3. 你是否跟學生時期一樣，教授要你要你寫一份C++作業，你把它全部寫在main()函數裡面，發生Bug無從查起。
   如果有這種情形請打0800-092-000，欸不是啦!，就要從新審視自己寫的程式是否有單一職責，以防止改變後會引起的漣漪效應。

O: 開放封閉原則 Open-Closed Principle (OCP)
簡單來說就是，對擴增開放，對修改封閉，我們不能修改程式碼，這部分讀者可能困惑，怎麼可能不改程式，的確，這原則是說面對改變，我們不應該改變既有的程式碼，而是應該擴充功能的方式新增。
我們時常看到有人寫了很多層的if else if/switch case，來增加在同一個函數，更好的做法應該是繼承抽象層，再多型實作(可參考我接下來麥當勞的例子)

L: 里氏替換原則 Liskov Substitution Principle (LSP)
談的是子類別繼承父類別，子類別針對父類別行為改變進行覆寫時，子類別透過多型實作，不至於違反父類別的合約
I: 介面隔離原則 Interface Segregation Principle (ISP)
面對不同的使用者，只能開放他所需要的使用介面，如此一來可以避免因為不相關的介面改變因而被迫改變

D: 依賴反轉原則 Dependency Inversion Principle (DIP)
一言以蔽之:依賴抽象而不依賴實體
我來講個很讓人印象深刻的例子，假如我今天是渣男，我同時跟林志玲與波多野結依交往，哪天一個不小心波多野叫成林志玲，完了要跪算盤ORZ，所以我學乖了以後統一叫寶貝。

我們更可以看到生活中的例子，過去的麥當勞，一個漢堡就出一種漢堡紙，麥香雞、雙牛堡、吉士堡，完全是個失敗的政策。

然而很快的麥當勞就出現這種依賴抽象不依賴實體的漢堡紙，一張漢堡紙(抽象)可以做出四種漢堡的實體。

你可以發現，此五大原則是不相同的原則，但又環環相扣的，可以發現他都是在講當你改變時，應該以怎樣的原則下去施作，這也應證我主管之前所說的:”以不變應萬變”，至今我才懂這句話真正不是要我們不變，而是說在不影響舊有邏輯下依SOILD原則應萬變。

希望今天的觀念有讓大家聽懂並且融會貫通，應用在程式上。

有任何問題歡迎下方留言，如果喜歡我的文章別忘了按讚、訂閱追蹤加分享唷!!
---我是分隔線-----------------------------------------------------------
PollyPO技術-前端設計轉前端工程師-JS踩坑雜記 30 天
喬依司-實作經典 JavaScript 30
五百億-Vue CLI + Firebase 雲端資料庫 30天打造簡易部落格及後臺管理
eien_zheng-前端小嘍嘍的Golang學習旅程_The journey of learning Golang